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
