[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