[explanation snipped, thanks!]
Nelson B wrote:
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.
This is where our the difference in our
world views leads our logic apart. For
you, if I may be so bold, a CA is trusted,
for me, what the user states is trusted.
So, I agree in broadbrush with those
first two statements. The question would
be where to go from there (realising that
Mozilla of course firmly plants its flag in
with the CA-is-trusted camp.)
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.
( I would say that Mozilla, as it seeks to hide the
"trust decision" behind a single binary padlock
(like all browsers), is definately trying to turn
trust into a binary decision. I'd certainly agree
that this is impossible, and it only works by
redefining trust as a series of statements traced
back to a random "third party" on the root list. )
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.)
(I think my comment still stands!)
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.
That's a good observation!
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.
Yes, you may be technically correct here, but
taking the hard line may ultimately slow down
the adoption of the system. Enforcing cert/PKCS11
cleanliness is not a costless choice, personally
I'd rather have a whole bunch of flakey chains
and people using them to send emails that are
at least encrypted than to not grant access to
crypto tech just because some remote third
party can't follow the instruction book. Sorting
out cert chains can always be done later ...
getting people to start thinking about crypto
email is hard enough without putting barriers
in their way.
If NSS has any fault here, it is in allowing incomplete cert chains to
be sent by email signers and SSL servers.
The real challenge is to show CAs how to make
money by following the (full?) instructions; which
of course must happen as otherwise they will
go out of business and we are all wasting a
precious load of time adding them in to the
root list. But, given the objective of delivering
a secure browsing experience to the average
user, we cannot rely on a CA having a business
clientele that will pay the bills without question;
Mozilla needs CAs that deal with people who
won't pay much money, if any at all.
iang
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
