Ian,
Ian G wrote:
Having read and mused on this "chicken and egg" problem, I see a
bunch of questions here. I doubt they will all be answered, but
food for thought:
1. If a root is compromised, how is it revoked and/or replaced?
By means of marking that cert as untrusted , or deleting that cert if
possible (which it's not in the case of the nssckbi root cert module).
2. If it is done by signing a revocation over self in CRL form, then:
a. Is NSS the authority on revocation, or is the application?
NSS is not an "authority" - it is a software library and merely
implements open standard PKIX protocols. It works with whatever standard
data you feed it.
Perhaps you are referring specifically to the root cert module component
of NSS, which is merely a bundled list of CA certs. It's possible to
write NSS applications and not use the root cert module. Many corporate
applications do so.
b. Once so revoked, are all following CRLs also "revoked"?
Certificates get revoked. CRLs don't get revoked.
In general, revocation is for a given issuer and serial number.
3. If not by self-signing, then:
a. Is removal from the root list a revocation? Semantically, is
that what removal means?
Removal from the root list accomplishes a similar goal to revocation -
the cert is no longer present, and thus is no longer trusted.
Any cert that would be so removed would have a lesser status which is
untrusted by default, much the same as the CA you are using to sign your
messages.
Marking the CA cert as untrusted is another way to do the same thing.
b. Is there a way in the root list (code) to signal that a root is
revoked (other than by a self-signed CRL of self)? E.g., by a flag
or something?
You can mark certs as untrusted in the root cert module. You can't mark
them as trusted.
The root cert module could be enhanced to also contain
standards-compliant CRLs, but no such CRL can be formed to revoke roots
because they have no issuer above them.
c. If not, how does the root list owner intend to "revoke" a root
when it goes rogue? For example, it is discovered that Acme CA Inc.
is now selling to scammers for bulk prices, or some other motive
where we can conveniently agree to employ the nuclear option.
Either by deleting the root CA from nssckbi, or marking it untrusted in
an update version, or updating the cert DB during upgrade to mark it
untrusted.
d. Can Eddy send an unsigned email to Frank asking for revocation,
and explain how the entire hierarchy is toast because of some disaster?
e. Can anyone else? :)
I would hope so. And that would be treated as a security-sensitive bug.
4. It is also possible to ask these questions of subroots; e.g.,
do the CRLs of a revoked subroot now stop working, and/or, are all
certificates of that revoked subroot now "super-revoked" ?
There is no need to reinvent any protocol. If a particular CA is no
longer trusted, then automatically none of the certs that chain back to
it are valid anymore. Same for CRLs.
5. At the higher or business or liability level, some observations:
a. CAs probably want some defined way to do root revocation.
This problem appears to have been handled in a vendor-specific manner so
far.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
