mace-opensaml-users - Re: Spec compliance at the cost of more dependencies?
Subject: OpenSAML user discussion
List archive
- From: Chad La Joie <>
- To:
- Subject: Re: Spec compliance at the cost of more dependencies?
- Date: Mon, 04 Dec 2006 09:48:48 -0600
- Organization: University Information Systems
It's not the tests that I'm worried about (those can be fixed). I'm worried about people trying to use this in some other product that ends up breaking because it relies on some Sun internal code (com.sun.* stuff) or something. We already see this in most webapp containers because they don't support JAXP 1.3 (which has only been out for like 3 years).
Anil Saldhana wrote:
This is an issue with all software projects that require JCE (unlimited cipher strength, US export laws etc). AFAIR key sizes above 128 need unlimited encryption strength policy files to be downloaded, which are governed by US export laws.
I think having the dependence on bouncy castle is fine. Is it possible to categorize these tests that require BC such that people who don't care ignore them, but those who want them can use BC. Atleast the core set of tests need to be usable by everyone.
On 12/4/06, *Chad La Joie* < <mailto:>> 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
--
Chad La Joie 2052-C Harris Bldg
OIS-Middleware 202.687.0124
- Spec compliance at the cost of more dependencies?, Chad La Joie, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Derek Morr, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Chad La Joie, 12/04/2006
- RE: Spec compliance at the cost of more dependencies?, Scott Cantor, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Chad La Joie, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Anil Saldhana, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Chad La Joie, 12/04/2006
- Re: Spec compliance at the cost of more dependencies?, Chad La Joie, 12/11/2006
- Re: Spec compliance at the cost of more dependencies?, Derek Morr, 12/04/2006
Archive powered by MHonArc 2.6.16.