[security-dev 00682]: Re: keytool: -import reply different when length is different

[Sean Mullan]

Weijun Wang wrote:
> Hi
> 
> In keytool's installReply(), there is:
> 
>         if (replyCerts.length == 1) {
>             // single-cert reply
>             newChain = establishCertChain(userCert, replyCerts[0]);
>         } else {
>             // cert-chain reply (e.g., PKCS#7)
>             newChain = validateReply(alias, userCert, replyCerts);
>         }
> 
> If the trust cannot be setup with a known trust anchor, in
> establishCertChain(), the import simply fails; in validateReply(), a
> prompt is displayed, and if you type yes, it's imported.
> 
> This means the user experience is different between directly applying
> for a cert from a root CA (in which the reply is a single cert) and from
> an intermediate CA (in which the reply includes the user's cert and the
> CA's cert), when the root CA is not in user's cacerts.
> 
> Is this rational? Why isn't validateReply() always be called?

The problem is that you don't know if the single cert is directly issued by a 
root CA or is missing some number of intermediate CA certs.

I agree though the behavior is strange. I think the user should be allowed to 
override and manually trust the chain, whether it is 1 cert or n certs. The 
keytool man page says this about the single cert reply:

"In this case, keytool does not print out the certificate and prompt the user to 
verify it, because it is very hard (if not impossible) for a user to determine 
the authenticity of the certificate reply."

I'm not sure why that trust decision is any more difficult whether the reply 
contains 1 cert or n certs. Maybe you can look at the source code and the 
history behind that?

Thanks,
Sean