OK, thanks for the explanation Colm! Let's add this to the release notes.
I agree in retrospective it would have been better to apply changes for
versions previous to 1.49 ;-)
Cheers
Alessio
On 14/07/14 12:46, Colm O hEigeartaigh wrote:
Hi Alessio,
Some changes were made in XML Security 2.0.1 with regards to GCM support.
Namely, JDK 8 requires that javax.crypto.spec.GCMParameterSpec be used
instead of IVParameterSpec. However the former is only available as of JDK
7. So the solution was to try to load it reflectively, and to fall back on
IVParameterSpec if it is not available.
However, BouncyCastle does not add support for GCMParameterSpec until 1.50,
and there is a bug which means it won't work properly until 1.51 is
released. So the solution in WSS4J 2.0.1 is to set a system property in
Santuario to force it to use IVParametersSpec if BouncyCastle v.1.49 is in
use. In retrospect it was a mistake not to do this for BouncyCastle <=
1.49, but this was only intended to be a temporary workaround until
BouncyCastle 1.51 is released. This is why the CXF systests are working
correctly.
So in a nutshell, we require one of the following things for GCM to work
with the next set of CXF releases:
a) Upgrade to BouncyCastle 1.49 (or 1.51 when it gets released) OR
b) Set the system property
"org.apache.xml.security.cipher.gcm.useIvParameterSpec" to "true".
Colm.
On Fri, Jul 11, 2014 at 3:42 PM, Alessio Soldano <[email protected]>
wrote:
Hi Dan,
I started testing the JBoss integration with current 3.0.1-SNAPSHOT and
noticed some issues with the WS-Security endpoints using GCM algorithms.
After updating both JDK and BouncyCastle I got past them, but I believe
the release notes should properly clarify the actual new version
requirements and backward compatibility limitations.
The exception I had was:
Caused by: java.security.InvalidAlgorithmParameterException: unknown
parameter type.
at org.bouncycastle.jce.provider.JCEBlockCipher.engineInit(Unknown
Source)
at javax.crypto.Cipher.implInit(Cipher.java:791) [jce.jar:1.7.0_10]
at javax.crypto.Cipher.chooseProvider(Cipher.java:849)
[jce.jar:1.7.0_10]
at javax.crypto.Cipher.init(Cipher.java:1348) [jce.jar:1.7.0_10]
at javax.crypto.Cipher.init(Cipher.java:1282) [jce.jar:1.7.0_10]
at org.apache.xml.security.encryption.XMLCipher.
encryptData(XMLCipher.java:1184)
at org.apache.xml.security.encryption.XMLCipher.
encryptData(XMLCipher.java:1134)
at org.apache.xml.security.encryption.XMLCipher.encryptElementContent(
XMLCipher.java:907)
at org.apache.xml.security.encryption.XMLCipher.doFinal(
XMLCipher.java:1038)
at
org.apache.wss4j.dom.message.WSSecEncrypt.encryptElement(WSSecEncrypt.java:602)
[wss4j-ws-security-dom.jar:2.0.1]
... 51 more
Cheers
Alessio
On 09/07/14 15:00, Daniel Kulp wrote:
Now that we have the new WSS4J releases, is there anything left
outstanding that would prevent releases of 2.6.15/2.7.12/3.0.1 later this
week or on Monday? If not, I’ll plan on doing the releases one of those
days.
I’m really looking forward to the 2.6.x release so we can drop that
version and start the 3.1 updates for Java7. :-)
--
Alessio Soldano
Web Service Lead, JBoss
--
Alessio Soldano
Web Service Lead, JBoss
