> I would like to hear what other members on the list think about going
> for this change.
>
> Vishal
>
> Davanum Srinivas wrote:
>
+1 for me, It simplifies the code that is very good, and it seems to ease
the burden of supporting several JCE/JRE(which I don't have experience as
I always using sun JRE)
>>Vishal,
>>
>>+1 from me.
>>
>>thanks,
>>dims
>>
>>
>>On Tue, 05 Oct 2004 04:40:46 +0000, Vishal Mahajan
>><[EMAIL PROTECTED]> wrote:
>>
>>
>>>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
>>>>
>>>>
>
>
