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