You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Sean Mullan <Se...@Sun.COM> on 2004/08/20 14:44:33 UTC
[java] config.xml and JCA/JCE provider issues
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
Re: [java] config.xml and JCA/JCE provider issues
Posted by Sean Mullan <Se...@Sun.COM>.
Davanum Srinivas wrote:
> Question: Are u suggesting that If the algName is not present in
> config.xml then use "single-argument getInstance(algName)"??
No. I am proposing to remove the JCE/JCA algName mappings from config.xml and to
instead use the "single-argument getInstance(algName)" and rely on the standard
J2SE configuration to find a provider instead.
--Sean
>
> -- dims
>
> PS: we are still supporting 1.3/1.4 right?
>
> On Fri, 20 Aug 2004 08:44:33 -0400, Sean Mullan <se...@sun.com> 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
>>
>>
>
>
>
Re: [java] config.xml and JCA/JCE provider issues
Posted by Davanum Srinivas <da...@gmail.com>.
Question: Are u suggesting that If the algName is not present in
config.xml then use "single-argument getInstance(algName)"??
-- dims
PS: we are still supporting 1.3/1.4 right?
On Fri, 20 Aug 2004 08:44:33 -0400, Sean Mullan <se...@sun.com> 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
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [java] config.xml and JCA/JCE provider issues
Posted by Vishal Mahajan <Vi...@Sun.COM>.
I'll go ahead and check-in the patch.
Vishal
Berin Lautenbach wrote:
> Sounds like a good thing to me!
>
> Vishal Mahajan wrote:
>
>> I would like to hear what other members on the list think about going
>> for this change.
>>
>> Vishal
>>
>> Davanum Srinivas wrote:
>>
>>> Vishal,
>>>
>>> +1 from me.
>>>
>>> thanks,
>>> dims
>>>
>>>
>>> On Tue, 05 Oct 2004 04:40:46 +0000, Vishal Mahajan
>>> <vi...@sun.com> 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
>>>>>
>>>>
>>
>>
>>
>>
Re: [java] config.xml and JCA/JCE provider issues
Posted by Berin Lautenbach <be...@wingsofhermes.org>.
Sounds like a good thing to me!
Vishal Mahajan wrote:
> I would like to hear what other members on the list think about going
> for this change.
>
> Vishal
>
> Davanum Srinivas wrote:
>
>> Vishal,
>>
>> +1 from me.
>>
>> thanks,
>> dims
>>
>>
>> On Tue, 05 Oct 2004 04:40:46 +0000, Vishal Mahajan
>> <vi...@sun.com> 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
>>>>
>
>
>
>
Re: [java] config.xml and JCA/JCE provider issues
Posted by Raul Benito <ra...@r-bg.com>.
> 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
>><vi...@sun.com> 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
>>>>
>>>>
>
>
RE: [java] config.xml and JCA/JCE provider issues
Posted by Scott Cantor <ca...@osu.edu>.
> I would like to hear what other members on the list think about going
> for this change.
I'm strongly in favor of it. We've been sort of fighting this mechanism and
having trouble with helping people that have unusual JCE requirements.
If I understand the change correctly, it will let people use the IBM JCE on
WebSphere without jumping through hoops.
-- Scott
Re: [java] config.xml and JCA/JCE provider issues
Posted by Vishal Mahajan <Vi...@Sun.COM>.
I would like to hear what other members on the list think about going
for this change.
Vishal
Davanum Srinivas wrote:
>Vishal,
>
>+1 from me.
>
>thanks,
>dims
>
>
>On Tue, 05 Oct 2004 04:40:46 +0000, Vishal Mahajan
><vi...@sun.com> 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
>>>
>>>
Re: [java] config.xml and JCA/JCE provider issues
Posted by Davanum Srinivas <da...@gmail.com>.
Vishal,
+1 from me.
thanks,
dims
On Tue, 05 Oct 2004 04:40:46 +0000, Vishal Mahajan
<vi...@sun.com> 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
>
>
> ? src/org/apache/xml/security/algorithms/diff.txt
> Index: src/org/apache/xml/security/algorithms/JCEMapper.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/algorithms/JCEMapper.java,v
> retrieving revision 1.24
> diff -u -r1.24 JCEMapper.java
> --- src/org/apache/xml/security/algorithms/JCEMapper.java 25 Sep 2004 19:42:22 -0000 1.24
> +++ src/org/apache/xml/security/algorithms/JCEMapper.java 4 Oct 2004 22:34:09 -0000
> @@ -19,7 +19,6 @@
>
> import java.security.Key;
> -import java.security.Provider;
> import java.security.Security;
> import java.util.ArrayList;
> import java.util.HashMap;
> @@ -47,10 +46,8 @@
>
> - private static Map uriToProvider = new HashMap();
> - private static Map cacheProviderIsInClassPath = new HashMap();
> + private static Map uriToJCEName = new HashMap();
>
> - private static Map providersMap = new HashMap();
> private static Map algorithmsMap = new HashMap();
>
> /**
> @@ -61,239 +58,37 @@
> */
> public static void init(Element mappingElement) throws Exception {
>
> - //JCEMapper._providerList = mappingElement;
> -
> - //Document doc = mappingElement.getOwnerDocument();
> - loadProviders((Element)mappingElement.getElementsByTagName("Providers").item(0));
> loadAlgorithms((Element)mappingElement.getElementsByTagName("Algorithms").item(0));
> }
>
> - static void loadProviders( Element providers) {
> - Element[] elements=XMLUtils.selectNodes(providers.getFirstChild(),Init.CONF_NS,"Provider");
> - for (int i=0;i<elements.length;i++) {
> - Element el=elements[i];
> - String id=el.getAttribute("Id");
> - List list=(List) providersMap.get(id);
> - if (list==null) {
> - list=new ArrayList();
> - }
> - list.add(new ProviderJCE(el));
> - providersMap.put(id,list);
> - }
> - }
> - static ProviderJCE getProvider(String id) {
> - List list=(List) providersMap.get(id);
> - if (list==null) {
> - return null;
> - }
> - return (ProviderJCE) list.get(0);
> -
> - }
> - static List getProviders(String id) {
> - List list=(List) providersMap.get(id);
> - if (list==null) {
> - return null;
> - }
> - return list;
> - }
> static void loadAlgorithms( Element algorithmsEl) {
> - Element[] algorithms=XMLUtils.selectNodes(algorithmsEl.getFirstChild(),Init.CONF_NS,"Algorithm");
> - for (int i=0;i<algorithms.length;i++) {
> - Element el=algorithms[i];
> - String id=el.getAttribute("URI");
> - Algorithm providerAlgoMap=new Algorithm(el);
> - Element []providerAlgos=XMLUtils.selectNodes(el.getFirstChild(),Init.CONF_NS,"ProviderAlgo");
> - for (int j=0;j<providerAlgos.length;j++) {
> - Element elp=providerAlgos[j];
> - AlgorithmMapping idA=new AlgorithmMapping(providerAlgoMap,elp);
> - providerAlgoMap.put(idA.ProviderId,idA);
> - }
> - algorithmsMap.put(id,providerAlgoMap);
> - }
> -
> - }
> - static AlgorithmMapping getAlgorithmMapping(String algoURI,String providerId) {
> - Map algo=(Map) algorithmsMap.get(algoURI);
> - return (AlgorithmMapping) algo.get(providerId);
> + Element[] algorithms = XMLUtils.selectNodes(algorithmsEl.getFirstChild(),Init.CONF_NS,"Algorithm");
> + for (int i = 0 ;i < algorithms.length ;i ++) {
> + Element el = algorithms[i];
> + String id = el.getAttribute("URI");
> + String jceName = el.getAttribute("JCEName");
> + uriToJCEName.put(id, jceName);
> + algorithmsMap.put(id, new Algorithm(el));
> + }
> }
> +
> static Algorithm getAlgorithmMapping(String algoURI) {
> return ((Algorithm)algorithmsMap.get(algoURI));
> }
> - /**
> - * This method takes a Provider ID and tries to register this provider in the JCE.
> - *
> - * @param Id the provider Id
> - * @return true if the provider was registerd
> - *
> - */
> - public static boolean addProvider(String Id) {
> -
> - try {
> - if (Security.getProvider(Id) == null) {
> - String providerClass = getProvider(Id).providerClass;
> - java.security.Provider prov =
> - (java.security.Provider) Class.forName(providerClass)
> - .newInstance();
> -
> - if (java.security.Security.getProvider(Id) == null) {
> - if (log.isDebugEnabled())
> - log.debug("The provider " + Id
> - + " had to be added to the java.security.Security");
> - java.security.Security.addProvider(prov);
> -
> - Provider registeredProvider =
> - java.security.Security.getProvider(Id);
> -
> - if (registeredProvider != null) {
> - return true;
> - }
> - }
> - }
> - }
> - catch (ClassNotFoundException ex) {}
> - catch (IllegalAccessException ex) {}
> - catch (InstantiationException ex) {}
> -
> - return false;
> - }
> -
> - /**
> - * Method getProviderIsAvailable
> - *
> - * @param providerId the id to search
> - * @return true if the provider is in the classpath
> - *
> - */
> - public static boolean getProviderIsInClassPath(String providerId) {
> -
> - boolean available = false;
> - Boolean isInClassPath=(Boolean) cacheProviderIsInClassPath.get(providerId);
> - if ((isInClassPath!=null) && isInClassPath.booleanValue()) {
> - //Don't cache the negatives one, in case that latter are added
> - //To the classpath
> - //FIXME: Can the above happend?
> - return true;
> - }
> -
> -
> - /* Allow for mulitple provider entries with same Id */
> - List providers = getProviders(providerId);
> -
> - for (int i = 0; available == false && i < providers.size(); i++) {
> - String providerClass = ((ProviderJCE)providers.get(i)).providerClass;
> - try {
> - java.security.Provider prov =
> - (java.security.Provider) Class.forName(providerClass).newInstance();
> -
> - if (prov != null) {
> - available = true;
> - }
> - } catch (ClassNotFoundException ex) {
> - //do nothing
> - } catch (IllegalAccessException ex) {
> - //do nothing
> - } catch (InstantiationException ex) {
> - //do nothing
> - }
> - }
> -
> - cacheProviderIsInClassPath.put(providerId,new Boolean(available));
> - return available;
> - }
> -
> - /**
> - * Return <CODE>true</CODE> if the Provider with the given
> - * <CODE>providerId</CODE> is available in {@link java.security.Security}.
> - *
> - * @param providerId
> - * @return <CODE>true</CODE> if the Provider with the given <CODE>providerId</CODE> is available in {@link java.security.Security}
> - */
> - public static boolean getProviderIsRegisteredAtSecurity(String providerId) {
> -
> - java.security.Provider prov =
> - java.security.Security.getProvider(providerId);
> -
> - if (prov != null) {
> - return true;
> - }
> -
> - return false;
> - }
> -
> - /**
> - * Method translateURItoJCEID
> - *
> - * @param AlgorithmURI
> - * @return the Provider that manages the given URI
> - *
> - */
> - public static ProviderIdClass translateURItoJCEID(String AlgorithmURI) {
> - if (log.isDebugEnabled())
> - log.debug("Request for URI " + AlgorithmURI);
> -
> - ProviderIdClass prov=(ProviderIdClass) uriToProvider.get(AlgorithmURI);
> - if (prov!=null) {
> - return prov;
> - }
> -
> -
> -
> -
> - Iterator providers=getAlgorithmMapping(AlgorithmURI)
> - .values()
> - .iterator();
> -
> - while (providers.hasNext()) {
> -
> - AlgorithmMapping map= (AlgorithmMapping)providers.next();
> -
> - if (JCEMapper.getProviderIsInClassPath(map.ProviderId)) {
> - JCEMapper.addProvider(map.ProviderId);
> -
> - ProviderIdClass result = new ProviderIdClass(map.JCEName,
> - map.ProviderId);
> - if (log.isDebugEnabled())
> - log.debug("Found " + result.getAlgorithmID() + " from provider "
> - + result.getProviderId());
> -
> - uriToProvider.put(AlgorithmURI,result);
> - return result;
> - }
> - }
> - return null;
> - }
>
> /**
> * Method translateURItoJCEID
> *
> * @param AlgorithmURI
> - * @param requestedProviderId
> - * @return the Provider that manages the given URI
> + * @return the JCE standard name corresponding to the given URI
> *
> */
> - public static ProviderIdClass translateURItoJCEID(String AlgorithmURI,
> - String requestedProviderId) {
> - if (log.isDebugEnabled())
> - log.debug("Request for URI " + AlgorithmURI + " from provider "
> - + requestedProviderId);
> -
> - if (!JCEMapper.getProviderIsInClassPath(requestedProviderId)) {
> - return null;
> - }
> -
> + public static String translateURItoJCEID(String AlgorithmURI) {
> + if (log.isDebugEnabled())
> + log.debug("Request for URI " + AlgorithmURI);
>
> -
> - String jceName = getAlgorithmMapping(AlgorithmURI,requestedProviderId).JCEName;
> -
> - JCEMapper.addProvider(requestedProviderId);
> -
> - ProviderIdClass result = new ProviderIdClass(jceName,
> - requestedProviderId);
> - if (log.isDebugEnabled())
> - log.debug("Found " + result.getAlgorithmID() + " from provider "
> - + result.getProviderId());
> -
> - return result;
> + String jceName = (String) uriToJCEName.get(AlgorithmURI);
> + return jceName;
> }
>
> /**
> @@ -305,46 +100,10 @@
> *
> */
> public static String getAlgorithmClassFromURI(String AlgorithmURI) {
> - if (log.isDebugEnabled())
> - log.debug("Request for URI " + AlgorithmURI);
> + if (log.isDebugEnabled())
> + log.debug("Request for URI " + AlgorithmURI);
>
> - Iterator alth=getAlgorithmMapping(AlgorithmURI).entrySet().iterator();
> - String uri=null;
> -
> - while (alth.hasNext()) {
> - String cur=((AlgorithmMapping)alth.next()).JCEName;
> - if (uri==null)
> - uri=cur;
> - if (log.isDebugEnabled())
> - log.debug("Found " + cur);
> - }
> -
> - return uri;
> -
> - }
> -
> - /**
> - * Method getKeyTypeFromURI
> - *
> - * @param AlgorithmURI
> - * @return the type of key used fpr the algorithm
> - */
> - public static int getKeyTypeFromURI(String AlgorithmURI) {
> -
> - String algoclass = getAlgorithmMapping(AlgorithmURI).algorithmClass;
> -
> -
> - if (algoclass.equals(JCEMapper.KEYTYPE_BLOCK_ENCRYPTION)) {
> - return javax.crypto.Cipher.SECRET_KEY;
> - } else if (algoclass.equals("Mac")) {
> - return javax.crypto.Cipher.SECRET_KEY;
> - } else if (algoclass.equals(JCEMapper.KEYTYPE_SYMMETRIC_KEY_WRAP)) {
> - return javax.crypto.Cipher.SECRET_KEY;
> - } else if (algoclass.equals(JCEMapper.KEYTYPE_KEY_TRANSPORT)) {
> - return javax.crypto.Cipher.SECRET_KEY;
> - }
> -
> - return -1;
> + return ((Algorithm) algorithmsMap.get(AlgorithmURI)).algorithmClass;
> }
>
> /**
> @@ -354,115 +113,29 @@
> * @return The length of the key used in the alogrithm
> */
> public static int getKeyLengthFromURI(String AlgorithmURI) {
> -
> -
> -
> - return Integer.parseInt(getAlgorithmMapping(AlgorithmURI).keyLength);
> -
> - }
> + return Integer.parseInt(((Algorithm) algorithmsMap.get(AlgorithmURI)).keyLength);
> + }
>
> /**
> * Method getJCEKeyAlgorithmFromURI
> *
> * @param AlgorithmURI
> - * @param ProviderId
> * @return The KeyAlgorithm for the given URI.
> *
> */
> - public static String getJCEKeyAlgorithmFromURI(String AlgorithmURI,
> - String ProviderId) {
> -
> -
> - return getAlgorithmMapping(AlgorithmURI,ProviderId).RequiredKey;
> -
> - }
> -
> -
> - /**
> - * @param AlgorithmURI
> - * @param ProviderId
> - * @return The IVJCEName for the given algorithm
> - */
> - public static String getJCEIVAlgorithmFromURI(String AlgorithmURI,
> - String ProviderId) {
> - return getAlgorithmMapping(AlgorithmURI,ProviderId).IVJCEName;
> -
> - }
> -
> - /** Field KEYTYPE_SYMMETRIC_KEY_WRAP */
> - public static final String KEYTYPE_SYMMETRIC_KEY_WRAP = "SymmetricKeyWrap";
> -
> - /** Field KEYTYPE_BLOCK_ENCRYPTION */
> - public static final String KEYTYPE_BLOCK_ENCRYPTION = "BlockEncryption";
> + public static String getJCEKeyAlgorithmFromURI(String AlgorithmURI) {
>
> - /** Field KEYTYPE_KEY_TRANSPORT */
> - public static final String KEYTYPE_KEY_TRANSPORT = "KeyTransport";
> + return ((Algorithm) algorithmsMap.get(AlgorithmURI)).requiredKey;
>
> - /**
> - * This takes a {@link Key} and one of the <CODE>JCEMapper.KEYTYPE_XXX</CODE>
> - * Strings and returns the algorithm for which this key is.
> - * <BR />
> - * Example: If you enter an AES Key of length 128 bit and the
> - * <CODE>JCEMapper.KEYTYPE_SYMMETRIC_KEY_WRAP</CODE>, the result is
> - * <CODE>EncryptionConstants.ALGO_ID_BLOCKCIPHER_AES128</CODE>.
> - *
> - *
> - * @param key
> - * @param type
> - * @return the URI for the given type and key length.
> - *
> - */
> - public static String getURIfromKey(Key key, String type) {
> -
> - String JCEalgo = key.getAlgorithm();
> - String keyLength = new Integer(key.getEncoded().length * 8).toString();
> -
> - //try {
> - //Attr URI = (Attr) cx.selectSingleNode(
> - //JCEMapper._providerList,
> - String xpath= "./x:Algorithms/x:Algorithm[@KeyLength='" + keyLength
> - + "' and @AlgorithmClass='" + type
> - + "']/x:ProviderAlgo[@RequiredKey='" + JCEalgo + "']/../@URI";
> - //,JCEMapper._nscontext);
> -
> - /*if (URI != null) {
> - return URI.getNodeValue();
> - }*/
> - //} catch (TransformerException ex) {
> - // log.debug("Found nothing: " + ex.getMessage());
> - //}
> -
> - return xpath;
> }
>
> - /*
> - public static String getWrapURIfromKey(Key key) {
> - return JCEMapper.getURIfromKey(key, JCEMapper.KEYTYPE_SYMMETRIC_KEY_WRAP);
> - }
> -
> - public static String getCipherURIfromKey(Key key) {
> - return JCEMapper.getURIfromKey(key, JCEMapper.KEYTYPE_BLOCK_ENCRYPTION);
> - }
> - */
> - /**
> - * Represents the ProviderJCE xml element
> - */
> - public static class ProviderJCE {
> - String providerClass;
> - /**
> - * Gets the data from element.
> - * @param el
> - */
> - public ProviderJCE(Element el) {
> - providerClass = el.getAttributeNS(null, "Class");
> - }
> - }
> /**
> * Represents the Algorithm xml element
> */
> - public static class Algorithm extends HashMap {
> + public static class Algorithm {
> String algorithmClass;
> String keyLength;
> + String requiredKey;
> /**
> * Gets data from element
> * @param el
> @@ -470,70 +143,7 @@
> public Algorithm(Element el) {
> algorithmClass=el.getAttribute("AlgorithmClass");
> keyLength=el.getAttribute("KeyLength");
> + requiredKey=el.getAttribute("RequiredKey");
> }
> - }
> - /**
> - * Represents the AlgorithmMapping xml element
> - */
> - public static class AlgorithmMapping {
> - String RequiredKey;
> - String ProviderId;
> - String JCEName;
> - String IVJCEName;
> - Algorithm algo;
> - /**
> - * Gets data from element
> - * @param algo
> - * @param el
> - */
> - public AlgorithmMapping(Algorithm algo,Element el) {
> - this.algo=algo;
> - RequiredKey=el.getAttribute("RequiredKey");
> - ProviderId=el.getAttribute("ProviderId");
> - JCEName=el.getAttribute("JCEName");
> - IVJCEName=el.getAttribute("IVJCEName");
> - }
> - }
> -
> - /**
> - * Class ProviderIdClass
> - *
> - * @author $Author: raul $
> - * @version $Revision: 1.24 $
> - */
> - public static class ProviderIdClass {
> -
> - /** Field _jceid */
> - private String _algorithmId;
> -
> - /** Field _providerClass */
> - private String _providerId;
> -
> - /**
> - * Constructor ProviderIdClass
> - *
> - * @param AlgorithmID
> - * @param ProviderId
> - */
> - protected ProviderIdClass(String AlgorithmID, String ProviderId) {
> - this._algorithmId = AlgorithmID;
> - this._providerId = ProviderId;
> - }
> -
> - /**
> - * Method getJceId
> - * @return The algorithmId of this provider
> - */
> - public String getAlgorithmID() {
> - return this._algorithmId;
> - }
> -
> - /**
> - * Method getProvider
> - * @return the providerId of this provider
> - */
> - public String getProviderId() {
> - return this._providerId;
> - }
> }
> }
> Index: src/org/apache/xml/security/algorithms/MessageDigestAlgorithm.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/algorithms/MessageDigestAlgorithm.java,v
> retrieving revision 1.14
> diff -u -r1.14 MessageDigestAlgorithm.java
> --- src/org/apache/xml/security/algorithms/MessageDigestAlgorithm.java 24 Sep 2004 20:54:27 -0000 1.14
> +++ src/org/apache/xml/security/algorithms/MessageDigestAlgorithm.java 4 Oct 2004 22:34:10 -0000
> @@ -82,8 +82,7 @@
> public static MessageDigestAlgorithm getInstance(
> Document doc, String algorithmURI) throws XMLSignatureException {
>
> - JCEMapper.ProviderIdClass algorithmID =
> - JCEMapper.translateURItoJCEID(algorithmURI);
> + String algorithmID = JCEMapper.translateURItoJCEID(algorithmURI);
>
> if (algorithmID == null) {
> Object[] exArgs = { algorithmURI };
> @@ -93,15 +92,9 @@
> MessageDigest md;
>
> try {
> - md = MessageDigest.getInstance(algorithmID.getAlgorithmID(),
> - algorithmID.getProviderId());
> + md = MessageDigest.getInstance(algorithmID);
> } catch (java.security.NoSuchAlgorithmException ex) {
> - Object[] exArgs = { algorithmID.getAlgorithmID(),
> - ex.getLocalizedMessage() };
> -
> - throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs);
> - } catch (java.security.NoSuchProviderException ex) {
> - Object[] exArgs = { algorithmID.getProviderId(),
> + Object[] exArgs = { algorithmID,
> ex.getLocalizedMessage() };
>
> throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs);
> Index: src/org/apache/xml/security/algorithms/implementations/IntegrityHmac.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/algorithms/implementations/IntegrityHmac.java,v
> retrieving revision 1.11
> diff -u -r1.11 IntegrityHmac.java
> --- src/org/apache/xml/security/algorithms/implementations/IntegrityHmac.java 25 Sep 2004 19:42:22 -0000 1.11
> +++ src/org/apache/xml/security/algorithms/implementations/IntegrityHmac.java 4 Oct 2004 22:34:12 -0000
> @@ -70,26 +70,17 @@
> */
> public IntegrityHmac() throws XMLSignatureException {
>
> - JCEMapper.ProviderIdClass algorithmID =
> - JCEMapper.translateURItoJCEID(this.engineGetURI());
> + String algorithmID = JCEMapper.translateURItoJCEID(this.engineGetURI());
> if (log.isDebugEnabled())
> - log.debug("Created IntegrityHmacSHA1 using "
> - + algorithmID.getAlgorithmID() + " "
> - + algorithmID.getProviderId());
> + log.debug("Created IntegrityHmacSHA1 using " + algorithmID);
>
> try {
> - this._macAlgorithm = Mac.getInstance(algorithmID.getAlgorithmID(),
> - algorithmID.getProviderId());
> + this._macAlgorithm = Mac.getInstance(algorithmID);
> } catch (java.security.NoSuchAlgorithmException ex) {
> - Object[] exArgs = { algorithmID.getAlgorithmID(),
> + Object[] exArgs = { algorithmID,
> ex.getLocalizedMessage() };
>
> throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs);
> - } catch (java.security.NoSuchProviderException ex) {
> - Object[] exArgs = { algorithmID.getProviderId(),
> - ex.getLocalizedMessage() };
> -
> - throw new XMLSignatureException("algorithms.NoSuchProvider", exArgs);
> }
> }
>
> Index: src/org/apache/xml/security/algorithms/implementations/SignatureBaseRSA.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/algorithms/implementations/SignatureBaseRSA.java,v
> retrieving revision 1.10
> diff -u -r1.10 SignatureBaseRSA.java
> --- src/org/apache/xml/security/algorithms/implementations/SignatureBaseRSA.java 25 Sep 2004 19:42:22 -0000 1.10
> +++ src/org/apache/xml/security/algorithms/implementations/SignatureBaseRSA.java 4 Oct 2004 22:34:12 -0000
> @@ -57,26 +57,18 @@
> */
> public SignatureBaseRSA() throws XMLSignatureException {
>
> - JCEMapper.ProviderIdClass algorithmID =
> - JCEMapper.translateURItoJCEID(this.engineGetURI());
> + String algorithmID = JCEMapper.translateURItoJCEID(this.engineGetURI());
> +
> if (log.isDebugEnabled())
> - log.debug("Created SignatureDSA using " + algorithmID.getAlgorithmID()
> - + " " + algorithmID.getProviderId());
> + log.debug("Created SignatureDSA using " + algorithmID);
>
> try {
> - this._signatureAlgorithm =
> - Signature.getInstance(algorithmID.getAlgorithmID(),
> - algorithmID.getProviderId());
> + this._signatureAlgorithm = Signature.getInstance(algorithmID);
> } catch (java.security.NoSuchAlgorithmException ex) {
> - Object[] exArgs = { algorithmID.getAlgorithmID(),
> + Object[] exArgs = { algorithmID,
> ex.getLocalizedMessage() };
>
> throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs);
> - } catch (java.security.NoSuchProviderException ex) {
> - Object[] exArgs = { algorithmID.getProviderId(),
> - ex.getLocalizedMessage() };
> -
> - throw new XMLSignatureException("algorithms.NoSuchProvider", exArgs);
> }
> }
>
> Index: src/org/apache/xml/security/algorithms/implementations/SignatureDSA.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/algorithms/implementations/SignatureDSA.java,v
> retrieving revision 1.11
> diff -u -r1.11 SignatureDSA.java
> --- src/org/apache/xml/security/algorithms/implementations/SignatureDSA.java 25 Sep 2004 19:42:22 -0000 1.11
> +++ src/org/apache/xml/security/algorithms/implementations/SignatureDSA.java 4 Oct 2004 22:34:12 -0000
> @@ -68,26 +68,17 @@
> */
> public SignatureDSA() throws XMLSignatureException {
>
> - JCEMapper.ProviderIdClass algorithmID =
> - JCEMapper.translateURItoJCEID(SignatureDSA._URI);
> + String algorithmID = JCEMapper.translateURItoJCEID(SignatureDSA._URI);
> if (log.isDebugEnabled())
> - log.debug("Created SignatureDSA using " + algorithmID.getAlgorithmID()
> - + " " + algorithmID.getProviderId());
> + log.debug("Created SignatureDSA using " + algorithmID);
>
> try {
> - this._signatureAlgorithm =
> - Signature.getInstance(algorithmID.getAlgorithmID(),
> - algorithmID.getProviderId());
> + this._signatureAlgorithm = Signature.getInstance(algorithmID);
> } catch (java.security.NoSuchAlgorithmException ex) {
> - Object[] exArgs = { algorithmID.getAlgorithmID(),
> + Object[] exArgs = { algorithmID,
> ex.getLocalizedMessage() };
>
> throw new XMLSignatureException("algorithms.NoSuchAlgorithm", exArgs);
> - } catch (java.security.NoSuchProviderException ex) {
> - Object[] exArgs = { algorithmID.getProviderId(),
> - ex.getLocalizedMessage() };
> -
> - throw new XMLSignatureException("algorithms.NoSuchProvider", exArgs);
> }
> }
>
> Index: src/org/apache/xml/security/encryption/XMLCipher.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/encryption/XMLCipher.java,v
> retrieving revision 1.28
> diff -u -r1.28 XMLCipher.java
> --- src/org/apache/xml/security/encryption/XMLCipher.java 2 Oct 2004 11:30:54 -0000 1.28
> +++ src/org/apache/xml/security/encryption/XMLCipher.java 4 Oct 2004 22:34:20 -0000
> @@ -285,19 +285,7 @@
> throw new XMLEncryptionException("empty", ice);
> }
>
> - String jceAlgorithm;
> - JCEMapper.ProviderIdClass provId =
> - JCEMapper.translateURItoJCEID(transformation);
> -
> - if (provId != null)
> - jceAlgorithm = provId.getAlgorithmID();
> - else {
> - Object exArgs[] =
> - { transformation,
> - "No provider found that supports this algorithm" };
> - throw new XMLEncryptionException("algorithms.NoSuchAlgorithm",
> - exArgs);
> - }
> + String jceAlgorithm = JCEMapper.translateURItoJCEID(transformation);
>
> try {
> instance._contextCipher = Cipher.getInstance(jceAlgorithm);
> @@ -389,7 +377,7 @@
>
> try {
> String jceAlgorithm =
> - JCEMapper.translateURItoJCEID(transformation).getAlgorithmID();
> + JCEMapper.translateURItoJCEID(transformation);
>
> instance._contextCipher = Cipher.getInstance(jceAlgorithm, provider);
>
> @@ -953,19 +941,15 @@
> Cipher c;
> if (_contextCipher == null) {
> String jceAlgorithm =
> - JCEMapper.translateURItoJCEID(_algorithm).getAlgorithmID();
> - String provider;
> + JCEMapper.translateURItoJCEID(_algorithm);
>
> - if (_requestedJCEProvider == null)
> - provider =
> - JCEMapper.translateURItoJCEID(_algorithm).getProviderId();
> - else
> - provider = _requestedJCEProvider;
> -
> - logger.debug("provider = " + provider + "alg = " + jceAlgorithm);
> + logger.debug("alg = " + jceAlgorithm);
>
> try {
> - c = Cipher.getInstance(jceAlgorithm, provider);
> + if (_requestedJCEProvider == null)
> + c = Cipher.getInstance(jceAlgorithm);
> + else
> + c = Cipher.getInstance(jceAlgorithm, _requestedJCEProvider);
> } catch (NoSuchAlgorithmException nsae) {
> throw new XMLEncryptionException("empty", nsae);
> } catch (NoSuchProviderException nspre) {
> @@ -1150,19 +1134,15 @@
> // Now create the working cipher
>
> String jceAlgorithm =
> - JCEMapper.translateURItoJCEID(_algorithm).getAlgorithmID();
> - String provider;
> -
> - if (_requestedJCEProvider == null)
> - provider =
> - JCEMapper.translateURItoJCEID(_algorithm).getProviderId();
> - else
> - provider = _requestedJCEProvider;
> + JCEMapper.translateURItoJCEID(_algorithm);
>
> - logger.debug("provider = " + provider + "alg = " + jceAlgorithm);
> + logger.debug("alg = " + jceAlgorithm);
>
> try {
> - c = Cipher.getInstance(jceAlgorithm, provider);
> + if (_requestedJCEProvider == null)
> + c = Cipher.getInstance(jceAlgorithm);
> + else
> + c = Cipher.getInstance(jceAlgorithm, _requestedJCEProvider);
> } catch (NoSuchAlgorithmException nsae) {
> throw new XMLEncryptionException("empty", nsae);
> } catch (NoSuchProviderException nspre) {
> @@ -1250,42 +1230,24 @@
> XMLCipherInput cipherInput = new XMLCipherInput(encryptedKey);
> byte [] encryptedBytes = cipherInput.getBytes();
>
> - String provider;
> - if (_requestedJCEProvider == null) {
> - JCEMapper.ProviderIdClass provId =
> - JCEMapper.translateURItoJCEID(
> - encryptedKey.getEncryptionMethod().getAlgorithm());
> - if (provId != null)
> - provider = provId.getProviderId();
> - else {
> - Object exArgs[] =
> - { encryptedKey.getEncryptionMethod().getAlgorithm(),
> - "No provider found that supports this algorithm" };
> - throw new XMLEncryptionException("algorithms.NoSuchAlgorithm",
> - exArgs);
> - }
> - }
> - else
> - provider = _requestedJCEProvider;
> -
> String jceKeyAlgorithm =
> - JCEMapper.getJCEKeyAlgorithmFromURI(algorithm, provider);
> - logger.debug("JCE Provider = " + provider);
> + JCEMapper.getJCEKeyAlgorithmFromURI(algorithm);
>
> Cipher c;
> if (_contextCipher == null) {
> // Now create the working cipher
>
> String jceAlgorithm =
> - JCEMapper
> - .translateURItoJCEID(
> - encryptedKey.getEncryptionMethod().getAlgorithm())
> - .getAlgorithmID();
> + JCEMapper.translateURItoJCEID(
> + encryptedKey.getEncryptionMethod().getAlgorithm());
>
> logger.debug("JCE Algorithm = " + jceAlgorithm);
>
> try {
> - c = Cipher.getInstance(jceAlgorithm, provider);
> + if (_requestedJCEProvider == null)
> + c = Cipher.getInstance(jceAlgorithm);
> + else
> + c = Cipher.getInstance(jceAlgorithm, _requestedJCEProvider);
> } catch (NoSuchAlgorithmException nsae) {
> throw new XMLEncryptionException("empty", nsae);
> } catch (NoSuchProviderException nspre) {
> @@ -1473,22 +1435,14 @@
> // Now create the working cipher
>
> String jceAlgorithm =
> - JCEMapper.translateURItoJCEID(encryptedData.getEncryptionMethod()
> - .getAlgorithm()).getAlgorithmID();
> - String provider;
> -
> - if (_requestedJCEProvider == null)
> - provider =
> - JCEMapper.translateURItoJCEID(encryptedData
> - .getEncryptionMethod()
> - .getAlgorithm())
> - .getProviderId();
> - else
> - provider = _requestedJCEProvider;
> + JCEMapper.translateURItoJCEID(encryptedData.getEncryptionMethod().getAlgorithm());
>
> Cipher c;
> try {
> - c = Cipher.getInstance(jceAlgorithm, provider);
> + if (_requestedJCEProvider == null)
> + c = Cipher.getInstance(jceAlgorithm);
> + else
> + c = Cipher.getInstance(jceAlgorithm, _requestedJCEProvider);
> } catch (NoSuchAlgorithmException nsae) {
> throw new XMLEncryptionException("empty", nsae);
> } catch (NoSuchProviderException nspre) {
> Index: src/org/apache/xml/security/keys/content/keyvalues/RSAKeyValue.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/keys/content/keyvalues/RSAKeyValue.java,v
> retrieving revision 1.11
> diff -u -r1.11 RSAKeyValue.java
> --- src/org/apache/xml/security/keys/content/keyvalues/RSAKeyValue.java 24 Sep 2004 20:54:29 -0000 1.11
> +++ src/org/apache/xml/security/keys/content/keyvalues/RSAKeyValue.java 4 Oct 2004 22:34:20 -0000
> @@ -111,7 +111,6 @@
> try {
> KeyFactory rsaFactory = KeyFactory.getInstance("RSA");
>
> - // String JCE_RSA = org.apache.xml.security.algorithms.JCEMapper.translateURItoJCEID(Constants.ALGO_ID_SIGNATURE_RSA);
> // KeyFactory rsaFactory = KeyFactory.getInstance(JCE_RSA);
> RSAPublicKeySpec rsaKeyspec =
> new RSAPublicKeySpec(this
> Index: src/org/apache/xml/security/resource/config.xml
> ===================================================================
> RCS file: /home/cvs/xml-security/src/org/apache/xml/security/resource/config.xml,v
> retrieving revision 1.39
> diff -u -r1.39 config.xml
> --- src/org/apache/xml/security/resource/config.xml 24 Jun 2004 10:43:51 -0000 1.39
> +++ src/org/apache/xml/security/resource/config.xml 4 Oct 2004 22:34:22 -0000
> @@ -82,417 +82,220 @@
> JAVACLASS="org.apache.xml.security.algorithms.implementations.IntegrityHmac$IntegrityHmacSHA512" />
> </SignatureAlgorithms>
> <JCEAlgorithmMappings>
> - <!-- Here, individual providers can be registered; each provider
> - is identified by Id which is referenced by ProviderId of the
> - Provider Element in the Algorithm Element -->
> - <Providers>
> - <Provider Id="BC"
> - Class="org.bouncycastle.jce.provider.BouncyCastleProvider"
> - Info="BouncyCastle Security Provider v1.09"
> - ProviderURL="http://www.bouncycastle.org/" />
> - <Provider Id="SUN"
> - Class="sun.security.provider.Sun"
> - Info="SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS keystore)"
> - ProviderURL="http://java.sun.com/" />
> - <Provider Id="SunRsaSign"
> - Class="com.sun.rsajca.Provider"
> - Info="SUN's provider for RSA signatures"
> - ProviderURL="http://java.sun.com/" />
> - <!-- Duplicate SunRsaSign is required to support JDK 1.5 -->
> - <Provider Id="SunRsaSign"
> - Class="sun.security.rsa.SunRsaSign"
> - Info="SUN's provider for RSA signatures (JDK 1.5)"
> - ProviderURL="http://java.sun.com/" />
> - <Provider Id="SunJCE"
> - Class="com.sun.crypto.provider.SunJCE"
> - Info="SunJCE Provider (implements DES, Triple DES, Blowfish, PBE, Diffie-Hellman, HMAC-MD5, HMAC-SHA1)"
> - ProviderURL="http://java.sun.com/" />
> - <Provider Id="IAIK"
> - Class="iaik.security.provider.IAIK"
> - Info="IAIK Security Provider v2.6"
> - ProviderURL="http://www.iaik.at/" />
> - <Provider Id="Cryptix"
> - Class="cryptix.provider.Cryptix"
> - Info="Cryptix JCE provider v3.001002"
> - ProviderURL="http://www.cryptix.org/" />
> - <Provider Id="IBMJCE"
> - Class="com.ibm.crypto.provider.IBMJCE"
> - Info="IBM JCE Provider"
> - ProviderURL="http://www.ibm.com/"/>
> - </Providers>
> <Algorithms>
> <!-- MessageDigest Algorithms -->
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#md5"
> Description="MD5 message digest from RFC 1321"
> AlgorithmClass="MessageDigest"
> RequirementLevel="NOT RECOMMENDED"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="MD5" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="MD5" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="MD5" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="MD5"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#ripemd160"
> Description="RIPEMD-160 message digest"
> AlgorithmClass="MessageDigest"
> - RequirementLevel="OPTIONAL">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="RIPEMD160" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="RIPEMD160" />
> - </Algorithm>
> + RequirementLevel="OPTIONAL"
> + JCEName="RIPEMD160"/>
> +
> <Algorithm URI="http://www.w3.org/2000/09/xmldsig#sha1"
> Description="SHA-1 message digest"
> AlgorithmClass="MessageDigest"
> - RequirementLevel="REQUIRED">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA-1" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="SHA-1" />
> - <ProviderAlgo ProviderId="IAIK"
> - JCEName="SHA-1" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="SHA-1" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="SHA1" />
> - </Algorithm>
> + RequirementLevel="REQUIRED"
> + JCEName="SHA-1"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#sha256"
> Description="SHA-1 message digest with 256 bit"
> AlgorithmClass="MessageDigest"
> - RequirementLevel="RECOMMENDED">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA-256" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="SHA-256" />
> - </Algorithm>
> + RequirementLevel="RECOMMENDED"
> + JCEName="SHA-256"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#sha384"
> Description="SHA message digest with 384 bit"
> AlgorithmClass="MessageDigest"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA-384" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="SHA-384" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="SHA-384"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#sha512"
> Description="SHA-1 message digest with 512 bit"
> AlgorithmClass="MessageDigest"
> - RequirementLevel="OPTIONAL">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA-512" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="SHA-512" />
> - </Algorithm>
> + RequirementLevel="OPTIONAL"
> + JCEName="SHA-512"/>
>
> <!-- Signature Algorithms -->
> <Algorithm URI="http://www.w3.org/2000/09/xmldsig#dsa-sha1"
> Description="Digital Signature Algorithm with SHA-1 message digest"
> AlgorithmClass="Signature"
> - RequirementLevel="REQUIRED">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="DSA" />
> - <ProviderAlgo ProviderId="SUN"
> - JCEName="DSAWithSHA1" />
> - <ProviderAlgo ProviderId="IAIK"
> - JCEName="DSA" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="SHA1WithDSA" />
> - </Algorithm>
> + RequirementLevel="REQUIRED"
> + JCEName="SHA1withDSA"/>
>
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#rsa-md5"
> Description="RSA Signature with MD5 message digest"
> AlgorithmClass="Signature"
> RequirementLevel="NOT RECOMMENDED"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="MD5WithRSAEncryption" />
> - <ProviderAlgo ProviderId="SunRsaSign"
> - JCEName="MD5WithRSA" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="MD5WithRSA" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="MD5withRSA"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#rsa-ripemd160"
> Description="RSA Signature with RIPEMD-160 message digest"
> AlgorithmClass="Signature"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="RIPEMD160WithRSAEncryption" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="RIPEMD160WithRSA"/>
> +
> <Algorithm URI="http://www.w3.org/2000/09/xmldsig#rsa-sha1"
> Description="RSA Signature with SHA-1 message digest"
> AlgorithmClass="Signature"
> - RequirementLevel="RECOMMENDED">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA1WithRSAEncryption" />
> - <ProviderAlgo ProviderId="SunRsaSign"
> - JCEName="SHA1withRSA" />
> - <ProviderAlgo ProviderId="IAIK"
> - JCEName="SHA-1/RSA" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="SHA-1/RSA" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="SHA1withRSA" />
> - </Algorithm>
> + RequirementLevel="RECOMMENDED"
> + JCEName="SHA1withRSA"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"
> Description="RSA Signature with SHA-256 message digest"
> AlgorithmClass="Signature"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA256withRSAEncryption" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="SHA256withRSA"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384"
> Description="RSA Signature with SHA-384 message digest"
> AlgorithmClass="Signature"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA384withRSAEncryption" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="SHA384withRSA"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"
> Description="RSA Signature with SHA-512 message digest"
> AlgorithmClass="Signature"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="SHA512withRSAEncryption" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="SHA512withRSA"/>
>
> <!-- MAC Algorithms -->
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#hmac-md5"
> Description="Message Authentication code using MD5"
> AlgorithmClass="Mac"
> RequirementLevel="NOT RECOMMENDED"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACMD5" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="HmacMD5" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="HMAC-MD5" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="HmacMD5"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#hmac-ripemd160"
> Description="Message Authentication code using RIPEMD-160"
> AlgorithmClass="Mac"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACRIPEMD160" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="HMACRIPEMD160"/>
> +
> <Algorithm URI="http://www.w3.org/2000/09/xmldsig#hmac-sha1"
> Description="Message Authentication code using SHA1"
> AlgorithmClass="Mac"
> - RequirementLevel="REQUIRED">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACSHA1" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="HmacSHA1" />
> - <ProviderAlgo ProviderId="IAIK"
> - JCEName="HMAC/SHA" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="HMAC-SHA-1" />
> - <ProviderAlgo ProviderId="IBMJCE"
> - JCEName="HMAC-SHA1" />
> - </Algorithm>
> + RequirementLevel="REQUIRED"
> + JCEName="HmacSHA1"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"
> Description="Message Authentication code using SHA-256"
> AlgorithmClass="Mac"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACSHA256" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="HmacSHA256" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="HmacSHA256"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#hmac-sha384"
> Description="Message Authentication code using SHA-384"
> AlgorithmClass="Mac"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACSHA384" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="HmacSHA384" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="HmacSHA384"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmldsig-more#hmac-sha512"
> Description="Message Authentication code using SHA-512"
> AlgorithmClass="Mac"
> RequirementLevel="OPTIONAL"
> - SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt">
> - <ProviderAlgo ProviderId="BC"
> - JCEName="HMACSHA512" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="HmacSHA512" />
> - </Algorithm>
> + SpecificationURL="http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt"
> + JCEName="HmacSHA512"/>
>
> <!-- Block encryption Algorithms -->
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"
> Description="Block encryption using Triple-DES"
> AlgorithmClass="BlockEncryption"
> RequirementLevel="REQUIRED"
> - KeyLength="192">
> - <ProviderAlgo ProviderId="BC"
> - RequiredKey="DESEDE"
> - JCEName="DESEDE/CBC/ISO10126PADDING"
> - IVJCEName="DESEDE/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="SunJCE"
> - RequiredKey="DESEDE"
> - JCEName="DESEDE/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="DES-EDE3/CBC" />
> - </Algorithm>
> + KeyLength="192"
> + RequiredKey="DESede"
> + JCEName="DESede/CBC/ISO10126PADDING"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#aes128-cbc"
> Description="Block encryption using AES with a key length of 128 bit"
> AlgorithmClass="BlockEncryption"
> RequirementLevel="REQUIRED"
> - KeyLength="128">
> - <ProviderAlgo ProviderId="BC"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="SunJCE"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="Rijndael" />
> - </Algorithm>
> + KeyLength="128"
> + RequiredKey="AES"
> + JCEName="AES/CBC/ISO10126PADDING"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#aes192-cbc"
> Description="Block encryption using AES with a key length of 192 bit"
> AlgorithmClass="BlockEncryption"
> RequirementLevel="OPTIONAL"
> - KeyLength="192">
> - <ProviderAlgo ProviderId="BC"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="SunJCE"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="Rijndael" />
> - </Algorithm>
> + KeyLength="192"
> + RequiredKey="AES"
> + JCEName="AES/CBC/ISO10126PADDING"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#aes256-cbc"
> Description="Block encryption using AES with a key length of 256 bit"
> AlgorithmClass="BlockEncryption"
> RequirementLevel="REQUIRED"
> - KeyLength="256">
> - <ProviderAlgo ProviderId="BC"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="SunJCE"
> - RequiredKey="AES"
> - JCEName="AES/CBC/ISO10126PADDING"
> - IVJCEName="AES/ECB/NOPADDING" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="Rijndael" />
> - </Algorithm>
> + KeyLength="256"
> + RequiredKey="AES"
> + JCEName="AES/CBC/ISO10126PADDING"/>
>
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-1_5"
> Description="Key Transport RSA-v1.5"
> AlgorithmClass="KeyTransport"
> - RequirementLevel="REQUIRED">
> - <!-- You have to provide a core RSA mechanism here, even for
> - the bouncy castle -->
> - <ProviderAlgo ProviderId="BC"
> - JCEName="RSA/ECB/PKCS1PADDING"
> - RequiredKey="RSA" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="RSA/ECB/PKCS1PADDING"
> - RequiredKey="RSA" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="RSA"
> - RequiredKey="RSA" />
> - <!-- <ProviderAlgo ProviderId="BC"
> - JCEName="RSA/PKCS1"
> - RequiredKey="RSA" />
> - <ProviderAlgo ProviderId="Cryptix"
> - JCEName="RSA/ECB/PKCS#1" /> -->
> - </Algorithm>
> + RequirementLevel="REQUIRED"
> + RequiredKey="RSA"
> + JCEName="RSA/ECB/PKCS1PADDING"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"
> Description="Key Transport RSA-OAEP"
> AlgorithmClass="KeyTransport"
> - RequirementLevel="REQUIRED">
> - <!-- You have to provide a core RSA mechanism here, even for
> - the bouncy castle -->
> - <ProviderAlgo ProviderId="BC"
> - JCEName="RSA/ECB/OAEPPADDING"
> - RequiredKey="RSA" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="RSA/ECB/OAEPWithSHA1AndMGF1Padding"
> - RequiredKey="RSA" />
> - <!-- <ProviderAlgo ProviderId="BC" JCEName="RSA/OAEP" RequiredKey="RSA" /> -->
> - </Algorithm>
> + RequirementLevel="REQUIRED"
> + RequiredKey="RSA"
> + JCEName="RSA/ECB/OAEPWithSHA1AndMGF1Padding"/>
>
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#dh"
> Description="Key Agreement Diffie-Hellman"
> AlgorithmClass="KeyAgreement"
> - RequirementLevel="OPTIONAL">
> - </Algorithm>
> + RequirementLevel="OPTIONAL"/>
>
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#kw-tripledes"
> Description="Symmetric Key Wrap using Triple DES"
> AlgorithmClass="SymmetricKeyWrap"
> RequirementLevel="REQUIRED"
> - KeyLength="192">
> - <!-- We need a Triple DES in CipherBlockChaining (CBC) mode here without padding -->
> - <ProviderAlgo ProviderId="BC"
> - RequiredKey="DESEDE"
> - JCEName="DESEDEWrap" />
> - <ProviderAlgo ProviderId="SunJCE"
> - RequiredKey="DESede"
> - JCEName="DESedeWrap" />
> - <!-- <ProviderAlgo ProviderId="BC" JCEName="DESEDEWrap" RequiredKey="DESEDE" /> -->
> - </Algorithm>
> + KeyLength="192"
> + RequiredKey="DESede"
> + JCEName="DESedeWrap"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#kw-aes128"
> Description="Symmetric Key Wrap using AES with a key length of 128 bit"
> AlgorithmClass="SymmetricKeyWrap"
> RequirementLevel="REQUIRED"
> - KeyLength="128">
> - <!-- We need an AES in ElectronicCodeBook (ECB) mode here without padding -->
> - <ProviderAlgo ProviderId="BC"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <!-- <ProviderAlgo ProviderId="BC" JCEName="AESWrap" RequiredKey="AES" /> -->
> - </Algorithm>
> + KeyLength="128"
> + RequiredKey="AES"
> + JCEName="AESWrap"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#kw-aes192"
> Description="Symmetric Key Wrap using AES with a key length of 192 bit"
> AlgorithmClass="SymmetricKeyWrap"
> RequirementLevel="OPTIONAL"
> - KeyLength="192">
> - <!-- We need an AES in ElectronicCodeBook (ECB) mode here without padding -->
> - <ProviderAlgo ProviderId="BC"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <!-- <ProviderAlgo ProviderId="BC" JCEName="AESWrap" RequiredKey="AES" /> -->
> - </Algorithm>
> + KeyLength="192"
> + RequiredKey="AES"
> + JCEName="AESWrap"/>
> +
> <Algorithm URI="http://www.w3.org/2001/04/xmlenc#kw-aes256"
> Description="Symmetric Key Wrap using AES with a key length of 256 bit"
> AlgorithmClass="SymmetricKeyWrap"
> RequirementLevel="REQUIRED"
> - KeyLength="256">
> - <!-- We need an AES in ElectronicCodeBook (ECB) mode here without padding -->
> - <ProviderAlgo ProviderId="BC"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <ProviderAlgo ProviderId="SunJCE"
> - JCEName="AESWrap"
> - RequiredKey="AES" />
> - <!-- <ProviderAlgo ProviderId="BC" JCEName="AESWrap" RequiredKey="AES" /> -->
> - </Algorithm>
> + KeyLength="256"
> + RequiredKey="AES"
> + JCEName="AESWrap"/>
> +
> </Algorithms>
> </JCEAlgorithmMappings>
> <ResourceBundles defaultLanguageCode="en" defaultCountryCode="US">
> Index: src_unitTests/org/apache/xml/security/test/encryption/BaltimoreEncTest.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src_unitTests/org/apache/xml/security/test/encryption/BaltimoreEncTest.java,v
> retrieving revision 1.16
> diff -u -r1.16 BaltimoreEncTest.java
> --- src_unitTests/org/apache/xml/security/test/encryption/BaltimoreEncTest.java 11 Jul 2004 21:48:30 -0000 1.16
> +++ src_unitTests/org/apache/xml/security/test/encryption/BaltimoreEncTest.java 4 Oct 2004 22:34:24 -0000
> @@ -182,12 +182,12 @@
> // Check what algorithms are available
>
> haveISOPadding = false;
> - JCEMapper.ProviderIdClass provId =
> + String algorithmId =
> JCEMapper.translateURItoJCEID(org.apache.xml.security.utils.EncryptionConstants.ALGO_ID_BLOCKCIPHER_AES128);
>
> - if (provId != null) {
> + if (algorithmId != null) {
> try {
> - if (Cipher.getInstance(provId.getAlgorithmID()) != null)
> + if (Cipher.getInstance(algorithmId) != null)
> haveISOPadding = true;
> } catch (NoSuchAlgorithmException nsae) {
> } catch (NoSuchPaddingException nspe) {
> Index: src_unitTests/org/apache/xml/security/test/encryption/XMLCipherTester.java
> ===================================================================
> RCS file: /home/cvs/xml-security/src_unitTests/org/apache/xml/security/test/encryption/XMLCipherTester.java,v
> retrieving revision 1.16
> diff -u -r1.16 XMLCipherTester.java
> --- src_unitTests/org/apache/xml/security/test/encryption/XMLCipherTester.java 11 Jul 2004 21:48:30 -0000 1.16
> +++ src_unitTests/org/apache/xml/security/test/encryption/XMLCipherTester.java 4 Oct 2004 22:34:24 -0000
> @@ -92,12 +92,12 @@
> // 3DES encryption
>
> haveISOPadding = false;
> - JCEMapper.ProviderIdClass provId =
> + String algorithmId =
> JCEMapper.translateURItoJCEID(org.apache.xml.security.utils.EncryptionConstants.ALGO_ID_BLOCKCIPHER_AES128);
>
> - if (provId != null) {
> + if (algorithmId != null) {
> try {
> - if (Cipher.getInstance(provId.getAlgorithmID()) != null)
> + if (Cipher.getInstance(algorithmId) != null)
> haveISOPadding = true;
> } catch (NoSuchAlgorithmException nsae) {
> } catch (NoSuchPaddingException nspe) {
>
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [java] config.xml and JCA/JCE provider issues
Posted by Vishal Mahajan <Vi...@Sun.COM>.
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