You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Leo Li <li...@gmail.com> on 2007/10/10 07:29:03 UTC
[classlib][security]Algorithm comparation should use locale neutral string manipulation.
Hi, all
I found that harmony has problem to get Signature under the Turkish Locale.
Here is an example:
// Enfore that providers information has been loaded.
Signature.getInstance("DSA");
Locale defaultLocale = Locale.getDefault();
try {
Locale.setDefault(new Locale("tr"));
Signature.getInstance("MD5withRSA");
} finally {
Locale.setDefault(defaultLocale);
}
It is due to we use algorithm.toUpperCase() as key to get
according instance from existing services. Although the algorithm
string actually only contain a limited charsets, under Turkish locale
the String.toUpperCase() will get the unexpected result:
"MD5withRSA".toUpperCase will get "MD5W?THRSA".
Thus it fails to get the signature instance from installed
providers since their information is updated under other locale.
Seems manipulations of Strings, including toUpperCase(),
toLowerCase() and equalsIgnoreCase(), shall use Locale.US when
treating with algorithm names and properties from config files in
security module since they will only contain chars in ASCII if I have
not missed something.
Besides in org.apache.harmony.security.x509.GeneralName.equals(Name)
and isAcceptable(GeneralName), shall we also use the locale neutral
means? If the string here is confined to ASCII, I think it does.
Good luck!
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][security]Algorithm comparation should use locale neutral
string manipulation.
Posted by Tim Ellison <t....@gmail.com>.
Leo Li wrote:
> On 10/10/07, Tim Ellison <t....@gmail.com> wrote:
>> I guess you will have to experiment to figure out if the name is locale
>> specific -- I don't see anything in the spec [1] to say the must be
>> ASCII, but that may be the case. If it is then you can use the LUNI
>> util [2] to uppercase it.
>
> It is really hard to prove the char range of acceptable algorithms.:)
> But I found that RI will report no such algorithm if the name is
> locale specific:
>
> Locale.setDefault(new Locale("tr"));
> Signature.getInstance("MD5withRSA".toUpperCase());
>
> This test to some degree shows that algorithm is acknowledged as
> locale neutral.
Agreed, so just treat it as ascii.
Regards,
Tim
>> [1] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA
>> [2] org.apache.harmony.luni.util.Util.toASCIIUpperCase(String)
>>
>> Regards,
>> Tim
>>
>
>
Re: [classlib][security]Algorithm comparation should use locale neutral string manipulation.
Posted by Leo Li <li...@gmail.com>.
On 10/10/07, Tim Ellison <t....@gmail.com> wrote:
> Leo Li wrote:
> > Hi, all
> > I found that harmony has problem to get Signature under the Turkish Locale.
> > Here is an example:
> >
> > // Enfore that providers information has been loaded.
> > Signature.getInstance("DSA");
> >
> > Locale defaultLocale = Locale.getDefault();
> > try {
> > Locale.setDefault(new Locale("tr"));
> > Signature.getInstance("MD5withRSA");
> > } finally {
> > Locale.setDefault(defaultLocale);
> > }
> >
> > It is due to we use algorithm.toUpperCase() as key to get
> > according instance from existing services. Although the algorithm
> > string actually only contain a limited charsets, under Turkish locale
> > the String.toUpperCase() will get the unexpected result:
> > "MD5withRSA".toUpperCase will get "MD5W?THRSA".
> > Thus it fails to get the signature instance from installed
> > providers since their information is updated under other locale.
> >
> > Seems manipulations of Strings, including toUpperCase(),
> > toLowerCase() and equalsIgnoreCase(), shall use Locale.US when
> > treating with algorithm names and properties from config files in
> > security module since they will only contain chars in ASCII if I have
> > not missed something.
> >
> > Besides in org.apache.harmony.security.x509.GeneralName.equals(Name)
> > and isAcceptable(GeneralName), shall we also use the locale neutral
> > means? If the string here is confined to ASCII, I think it does.
>
> I guess you will have to experiment to figure out if the name is locale
> specific -- I don't see anything in the spec [1] to say the must be
> ASCII, but that may be the case. If it is then you can use the LUNI
> util [2] to uppercase it.
It is really hard to prove the char range of acceptable algorithms.:)
But I found that RI will report no such algorithm if the name is
locale specific:
Locale.setDefault(new Locale("tr"));
Signature.getInstance("MD5withRSA".toUpperCase());
This test to some degree shows that algorithm is acknowledged as
locale neutral.
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA
> [2] org.apache.harmony.luni.util.Util.toASCIIUpperCase(String)
>
> Regards,
> Tim
>
--
Leo Li
China Software Development Lab, IBM
Re: [classlib][security]Algorithm comparation should use locale neutral
string manipulation.
Posted by Tim Ellison <t....@gmail.com>.
Leo Li wrote:
> Hi, all
> I found that harmony has problem to get Signature under the Turkish Locale.
> Here is an example:
>
> // Enfore that providers information has been loaded.
> Signature.getInstance("DSA");
>
> Locale defaultLocale = Locale.getDefault();
> try {
> Locale.setDefault(new Locale("tr"));
> Signature.getInstance("MD5withRSA");
> } finally {
> Locale.setDefault(defaultLocale);
> }
>
> It is due to we use algorithm.toUpperCase() as key to get
> according instance from existing services. Although the algorithm
> string actually only contain a limited charsets, under Turkish locale
> the String.toUpperCase() will get the unexpected result:
> "MD5withRSA".toUpperCase will get "MD5W?THRSA".
> Thus it fails to get the signature instance from installed
> providers since their information is updated under other locale.
>
> Seems manipulations of Strings, including toUpperCase(),
> toLowerCase() and equalsIgnoreCase(), shall use Locale.US when
> treating with algorithm names and properties from config files in
> security module since they will only contain chars in ASCII if I have
> not missed something.
>
> Besides in org.apache.harmony.security.x509.GeneralName.equals(Name)
> and isAcceptable(GeneralName), shall we also use the locale neutral
> means? If the string here is confined to ASCII, I think it does.
I guess you will have to experiment to figure out if the name is locale
specific -- I don't see anything in the spec [1] to say the must be
ASCII, but that may be the case. If it is then you can use the LUNI
util [2] to uppercase it.
[1] http://java.sun.com/j2se/1.5.0/docs/guide/security/CryptoSpec.html#AppA
[2] org.apache.harmony.luni.util.Util.toASCIIUpperCase(String)
Regards,
Tim
Re: [classlib][security]Algorithm comparation should use locale neutral string manipulation.
Posted by Spark Shen <sm...@gmail.com>.
What if there is a service provider named in Turkish? Will using English
locale also fail under such situation?
2007/10/10, Leo Li <li...@gmail.com>:
>
> Hi, all
> I found that harmony has problem to get Signature under the Turkish
> Locale.
> Here is an example:
>
> // Enfore that providers information has been loaded.
> Signature.getInstance("DSA");
>
> Locale defaultLocale = Locale.getDefault();
> try {
> Locale.setDefault(new Locale("tr"));
> Signature.getInstance("MD5withRSA");
> } finally {
> Locale.setDefault(defaultLocale);
> }
>
> It is due to we use algorithm.toUpperCase() as key to get
> according instance from existing services. Although the algorithm
> string actually only contain a limited charsets, under Turkish locale
> the String.toUpperCase() will get the unexpected result:
> "MD5withRSA".toUpperCase will get "MD5W?THRSA".
> Thus it fails to get the signature instance from installed
> providers since their information is updated under other locale.
>
> Seems manipulations of Strings, including toUpperCase(),
> toLowerCase() and equalsIgnoreCase(), shall use Locale.US when
> treating with algorithm names and properties from config files in
> security module since they will only contain chars in ASCII if I have
> not missed something.
>
> Besides in org.apache.harmony.security.x509.GeneralName.equals(Name)
> and isAcceptable(GeneralName), shall we also use the locale neutral
> means? If the string here is confined to ASCII, I think it does.
+1.
Good luck!
> --
> Leo Li
> China Software Development Lab, IBM
>
--
Spark Shen
China Software Development Lab, IBM