On 09/25/2009 04:39 PM, Kathleen Wilson wrote:
Note that I am operating under the assumption that there is currently
no way in NSS to mark a root certificate as “untrusted”. Please let me
know if this assumption is incorrect.
There are 3 states we can report about a certificate: trusted, unknown,
and untrusted.
These are colapsed from all our potential sources of trust into: the
trust bit is own, or the trust bit is off. Certs in which the trust bit
is off can still be trusted if the cert itself is signed by another cert
which chains to a trusted root. For Root certs, trust bit off means the
root cert is not trusted.
Trust can come from multiple tokens. Usually, however it's softoken (the
user's database) and the builtins (our root cert list). Each token as a
value called trustOrder, from 0 to 100. The smaller the trust order, the
higher the precidence. Softoken is typically 50 and builtins are
typically 100. This means if softoken has the cert in it's database with
some trust attributes on it, those attributes will always override
whatever we ship in the builtins module.
If it would be reasonable to mark a root cert as “untrusted” in NSS,
we could also consider this option... If a root were to be
compromised, and marked as untrusted, it could be treated as though
all of the trust bits are unset, and not allow the user to set any of
the trust bits. This would be safer than removing the root from NSS,
because it would prevent the user from importing and trusting the
root.
Because of the way the system works, deleting a cert from builtins would
be equivalent to marking it untrusted. The user could still override our
choice in softoken. Unfortunately the trustorder is set on the module,
not the slot (/me mentally slapping myself for that), otherwise we could
add a second slot in the builtins which had certs which had a lower
trust order than softoken. We could then put disabled certs in that
second token. It's probably not to difficult to give each slot it's own
trust order that overrides the overall module trust order, but it would
have to be added to NSS.
This means the feature is probably implementable without a lot of work,
but then the question becomes, do we really want to do this? Once
implemented, it would be very difficult to turn off (Hmm, well perhaps
PSM could control whether or not the 'disabled certs' override the other
trust flags as well or not.
We should probably have that discussion before we decide to do 'forced
turn-offs' on certificates.
bob
I look forward to your constructive input on the creation of this
policy and process.
Kathleen
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
