Ian G wrote:
I wrote:
I'd sooner guess that TBird is automatically marking the imported CA cert as trusted. That would be a serious bug in TB.
When a user imports a .p12 file (which is often described, somewhat incorrectly as importing "a cert"), he imports a private key, the corresponding public key cert, and usually one or more issuer certs, forming the entire CA cert chain. If the .p12 file contains an incomplete chain, mozilla imports what it can (and no more, obviously).
At one time (perhaps also presently), if the last cert in the chain from the .p12 file was not a known root CA cert, and was not issued by a known root CA cert, then mozilla would offer the user the opportunity to set the trust bit(s) on that last cert at time of import.
In my above quoted remark, I guessed that mozilla is now automatically setting trust bits on the last cert in a chain imported from a .p12 file. IMO, that would be a serious bug, if for no other reason that it fails to alert the user to the problem that he has a cert with an incomplete cert chain. One consequence of having an incomplete cert chain, with a trusted intermediate CA, is that if that user then sends out a signed email, that email will also include only the incomplete cert chain. That's bad. Now, having to get the missing certs to complete the chain has become the email recipient's problem.
When a user imports a .p12 file with an incomplete cert chain (or more, precisely, when importing a .p12 file leaves the user's DB unable to reconstruct the complete cert chain), the user should in notified of that fact, so that he can remedy the problem before it becomes other users' problems also. Setting a trust flag, instead of resolving the problem, only makes the real problem harder to diagnose, and may lead to accusations that mozilla doesn't validate chains, etc, as we have seen here.
David Ross wrote:If you have an
intermediate certificate in your database, you can mark it trusted
without having the root certificate, in which case you don't need
the root certificate.
That makes a lot of sense to me. Then, the
only question would be what would be the
default trust setting of an intermediate cert
entered explicity by user action.
The default trust setting should be no trust setting. Neither explicitly trusted, nor explicitly distrusted. Trust will be inherited from a trusted cert farther up the chain.
To my mind that would be automaticaly 'trusted' as the
user has done the action, which implies trust.
The cert chain validation stops at the first cert that is explicitly marked trusted. So, you do not generally want your intermediate CA certs marked trusted, unless you have some reason to distrust the root, but still wish to trust some subtree of that root CA's space.
(Any alternate, like 'not trusted' would raise the odd question of why the user did that in the first place.... And if the user can enter intermediate certs, then they can probably cope with finding the trust button and unsetting it.)
I think you're imaginging that mozilla's trust is binary. It's not. There are at least 3 states: - Definite trust (stop here in this cert chain, positive result) - Definite distrust (stop here in this cert chain, negative result) - indefinite trust (depends on whether this CA's chain is valid (that is, chains to a trusted CA) for the intended purpose, e.g. email, SSL server, etc.)
One thing is becoming clear to me. Some of the CAs that have been newly admitted to mozilla's trusted CA list are rather inexperienced, and are not ensuring that their users (the people to whom they issue certs) are getting the FULL cert chains for the certs being issued to them. This leads to many problems, which the newbie CAs are quick to blame on mozilla.
The solution to these ills is not to further burden the so-called "relying parties" with more duties to somehow obtain intermediate CA certs from various places (all strange to them), but rather is to ensure that the people with direct relationships with the CAs (those who request that certs be issued to them) get the full chains, and send/use the full chains in their email clients and SSL servers.
If NSS has any fault here, it is in allowing incomplete cert chains to be sent by email signers and SSL servers.
-- Nelson B _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
