Nelson,
Nelson Bolyard wrote:
David Stutzman wrote:
I don't know if this has been covered here before. I did a quick search
through bugzilla and didn't find anything so here goes. If this isn't
an existing issue I'll be happy to file a feature request bug. I was
thinking about how the certificate trust settings gui works and if you
select all the trust settings for a root CA you do not have to select
any options at all for any subordinate CAs. If you open the trust
dialog for a subordinate CA whose root CA is fully trusted then usually
all the check boxes are left blank. What would be nice to see is a
grayed out check box for all the trust settings that are being inherited
from above the current CA you are looking at so you can tell that this
CA *IS* being trusted.
Dave
AFAIK, no one has previously requested an indicator of inherited trust,
but it seems reasonable to me. Please file an RFE in bugzilla. Thanks.
But trust actually is not inherited. Trust to NSS means that the cert
validation ends at the trusted certificate - no other issuing
certificates are searched.
In the above case, the CA is not trusted, so the NSS cert validation
algorithm has to keep looking for certs until it finds a trusted one -
or not, and it must verify the larger chain that includes all the certs
up to a trust anchor. But there are also many things other than
trust/lack of trust that can prematurely abort the cert validation - for
example constraints, key usage / extended key usage extension values in
the issuing certs. All that you really have is a trust anchor that may
be part of the same chain as your CA cert, which means there is a
possibility that some certs from that CA may be validated.
Showing a tree of trust would be useful, but this only makes sense in
the context of a given cert chain, not in the context of the trust
properties of an isolated CA cert. Without a cert chain, there will be
no trusted cert to get trust bits from, since the particular CA is
untrusted.
One must consider that cert chains are not static, and even for a unique
CA cert, there can be several chains to be considered.
A CA cert can have multiple issuer certs that match it, the most common
case being if the issuing cert is renewed with a different date. But
other cert attribute may change too in the renewed cert, such as
constraints or key usage extensions.
The current cert validation in NSS always chains a cert to the newest
issuer cert, even though that may not have trust set, for example
because that second issuer cert came over SSL or in an S/MIME message.
Lack of trust may in turn cause cert validation to fail.
Since the certs from the peer may be only temporary decoded and
destroyed by the application during the processing of the SSL connection
or S/MIME message, there would be no opportunity for a mozilla browser
user to see in the GUI that any of this happened - the second issuer
cert wouldn't show at the time the user clicks. So, this type of UI may
create as many problems as it will resolve.
The right place to deal with this type of problem is when the
application encounters a cert chain it can't verify. Then it can display
the whole cert chain, including any trust properties - but we already
know implicitly that any cert part of the invalid chain isn't trusted
for the purpose being tested, or the validation would have succeeded.
Note that in the near future, NSS will be able to explore many more cert
trees, and will not always select the newest cert as the issuing cert
anymore. If the cert validation with the newest cert fails, other cert
trees will be explored. This means there may be several chains
considered during the validation - each with cert containing different
trust. That makes the validation algorithm much more forgiving, but it
also outlines the need for selecting a cert chain to use to get original
trust from.
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
