All:
Based on Sean's proposal I have prepared a patch (attached) that
eliminates the need of configuring JCE/JCA providers in config.xml. The
new code would also work well with the hardware-based providers. The key
points to observe are -
1) No providers are configured in config.xml any more. The <Algorithm>
element has been given a couple of new attributes - "RequiredKey" and
"JCEName" whose values are based on the standard algorithm names as
defined in [1]. Note that we longer need to own the responsibility of
maintaining the config.xml based on various providers' requirements.
2) Consider an algorithm implementation class, e.g., SignatureBaseRSA,
it now initializes the delegate java.security.Signature object using the
single argument c'tor (java.security.Signature.getInstance(algorithmID))
instead of the two argument one being used earlier.
3) Change in XMLCipher similar to 2. Only when the
XMLCipher.getProviderInstance() method is used, the providerID is passed
for javax.crypto.Cipher instantiation.
4) JCEMapper has become very simplified and it no longer keeps track of
any providers.
There's one known issue as of now with this patch. For rsa-oaep
algorithm, SunJCE provider supports "OAEPWithSHA1AndMGF1Padding" whereas
BC provider supports "OAEPPADDING". So a single configuration of this
algorithm doesn't work with both the providers. But it turns out that
according to [1], BC isn't using the standard name for the padding and
hence this qualifies as a bug on BC. I have raised this issue on BC
mailing list. In this particular case, "OAEPWithSHA1AndMGF1Padding" has
been associated with the algorithm.
Please let me know your views on this patch.
Thanks,
Vishal
[1] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA
Sean Mullan wrote:
Hi,
Recently, we have run into a serious issue with the Apache XML
Security Java implementation due to the way it uses its own mechanism
(config.xml) to find JCA/JCE providers for different XML DSig or Enc
algorithm URIs instead of using the standard J2SE mechanism [1].
The issue involves finding an appropriate hardware or software based
provider. In JDK 5 (1.5), we have added support for crypto tokens via a
PKCS#11 provider [2]. In order to find an appropriate hardware or
software based provider, it was necessary to delay the selection of the
provider for some JCA objects until the key is passed in [3].
Unfortunately, this solution doesn't work with the Apache implementation
because it instantiates specific providers as configured by the
config.xml file. The config.xml solution will only work with software
keys. It will not work with hardware keys.
Another more general issue is that this configuration overrides the
J2SE provider configuration, so developers cannot reuse existing
configurations and need to learn and reconfigure a new one.
I understand that part of the problem and the original need for
config.xml was that different providers used different algorithm names
for some of the XML DSig and Enc algorithms, so it was not possible to
instantiate JCA/JCE objects that would work across all providers. But I
believe that most of those problems have been addressed and standard
algorithm names have been added to the JCA/JCE reference guides [4, 5].
To avoid these issues, Vishal Mahajan and I would like to propose
changing the XMLSec implementation to find JCA/JCE providers using the
single-argument getInstance(algName) methods. This is a solution that
requires no configuration and is designed to work with software and
hardware based JCA/JCE providers w/o changing code. The current
config.xml is still useful for mapping non-cryptographic algorithm
URIs or proprietary/non-standard algorithm URIs, but shouldn't be used
to map URIs to well-known, standard JCA/JCE algorithms.
Comments?
[1]:
http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html#ProviderImplReq
[2]:http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.html
[3]:http://java.sun.com/j2se/1.5.0/docs/guide/security/p11guide.html#DelayedSelect
[4]:http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA
[5]:http://java.sun.com/j2se/1.5.0/docs/guide/security/jce/JCERefGuide.html#AppA
--Sean
