OpenSAML user discussion

[Chad La Joie <>]

Just to follow up on this.  After talking with a few people here at the 
Internet2 member meeting about this I've decided not to require bouncy 
castle as the JCE.  If there are things that are not supported by the 
JCE a deployment uses they will just get exception about it being 
unsupported.  That said, BouncyCastle is still going to be required (as 
a library) because I need things out of it (like its ASN.1 parser).  So 
it will ship with the library and if people want enable it as their JCE 
they'll already have a copy of it.

Chad La Joie wrote:
> As some people have noted the current XMLTooling unit tests do not pass, 
> giving an error about keysizes.  Hidden underneath this problem is a 
> deeper issue (isn't that always the case).  The Java JCE does not 
> support a given set of functionality that is going to be required for 
> specification compliance in areas like digital signing and encryption. 
> For example, one spec requires support for AES 128 and 256 yet the Sun 
> JCE doesn't support that algorithm.
>
> So, here's the question.  For those using the Sun JRE, is requiring a 
> dependency on a different JCE, e.g. bouncycastle, acceptable or are you 
> willing to forgo specification compliance in order to avoid another 
> dependency?
>
> I restrict this question to the Sun JRE because I do not know what other 
> JRE's JCEs implement, I just know the Sun one doesn't do everything that 
> would be needed (and I suspect most of the others don't as well).

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124