Intended behavior of the -providerName option of keytool
Wang Weijun
weijun.wang at oracle.com
Fri Sep 16 06:25:29 UTC 2016
> On Sep 15, 2016, at 11:53 PM, Michael Wang <muuang at gmail.com> wrote:
>
> Hi,
>
> I'm trying to understand what the -providerName option of keytool does. The documentation for -providerName just says:
>
> "Used to identify a cryptographic service provider's name when listed in the security properties file."
>
> Which doesn't really say anything about how it should be used and the resulting behavior.
>
> I looked at the latest Java 9 source code for keytool, the only 2 places that I see that uses providerName are
>
> a. Getting an instance of the keystore, with:
> KeyStore.getInstance(storetype, providerName);
>
> b. Getting an instance of key pair generator, with:
> new CertAndKeyGen(keyAlgName, sigAlgName, providerName);
>
> It looks like all other calls in keytool that requires the services of a provider does not use providerName, so it defaults to looking up the matching provider from the providers list.
>
> This behavior doesn't seem very clear cut to me.
> I think -providerName should used to either:
>
> 1. Specify the provider of the keystore only. All other services used by keytool that requires a provider will look up the provider using the default providers list.
>
> 2. Specify the provider of all services used by keytool that requires a provider, including keystore.
This is the intended behavior. However, we only use providerName when it's necessary:
The reason why you see it is not used everywhere can be due to several reasons:
1. storetype is already different for different providers so it's not necessary.
2. some object is smart enough to switch provider even after getInstance. For example, if you call sig = Signature.getInstance("SHA1withRSA") to get a signature object it is not actually fully initialized. Next when you call sig.initSign(key), it will use the provider of key as its provider if necessary.
Thanks
Max
>
> I just want to understand what the intended behavior should be.
>
> Thanks,
> Michael Wang
More information about the security-dev
mailing list