OpenSAML user discussion

[Brent Putman <>]

Clifford Johnson wrote:
> Now for the ExplicitKeySignatureTrustEngineTest failures ... each test
> case in the class failed dues to an issue with the signing private key
> included in the class.  The stack trace for the failure is in the
> attached file ExplicitKeySignatureTrustEngineTest_stacktrace.txt.  It
> would appear that the base-64 encoded key has some fault when processed
> in my environment.  
> 	As a point of information, I do *not* have the
> BouncyCastle JCE library registered as a provider in my Java environment
> (I have to avoid it due to the licensing requirements for at least one
> of the crypto algorithms it contains). 


Ok, yes, it failed for me too on my new dev machine, on which I have not 
(yet) installed Bouncy Castle as a provider.   :-(   That environment 
was MacOS X Leopard (so Apple's Java 1.5).  On my other dev machine, I 
know it was working on Sun's JDK 1.5 for Windows with the BC security 
provider installed.


>  I'll continue trying to find the
> issue with the key but, in the mean time, what is the origin of the
> encoded key?

I believe I generated it with OpenSSL genrsa.


I'll test on Windows too, but I would guess that Sun's (which 
essentially includes Apple too, I think) standard RSA KeyFactory 
provider doesn't like the PKCS8 key spec produced from the DER-encoded 
key from OpenSSL.  I wrote that test helper code awhile back.  In the 
rest of the OpenSAML stack we actually now use another library 
(not-yet-commons-ssl.jar) for handling keys, because of its robust 
support for various encodings and formats, etc.  So I have just switched 
this test helper method over to use that instead and it seems to work ok 
for me now.  Try r489 of java-xmltooling.


>   Does it *require* BouncyCastle as the primary provider for
> proper processing?
>   


It has not been our intention to *require* BouncyCastle as a configured 
Java security provider and I think that is still strictly true.  
However, depending on your JRE and what it supports by default, some 
things will not work without another provider like BouncyCastle.   This 
comes from mandatory algorithms, etc that are dictated by the XML 
Signature and XML Encryption specs, and will be directly in line with 
with works (or not) with the Apache XML Security lib that we use.   I 
don't have a list of the specific issues offhand, mostly they were 
related to support for larger key sizes, etc.  However, for example, as 
of spring 2007 (may have now changed), you could not support XML 
Encryption with IBM's JRE because they didn't support the required 
padding scheme outlined in that spec.

Be aware, however, that we do require the BC provider jar as a library 
dependency (not as a security provider) of the OpenSAML stack, because 
we are using their library for some functionality (ASN.1 processing, IIRC).

HTH,
Brent