Ian G:
b. Once so revoked, are all following CRLs also "revoked"?
The CRL would have to be valid until the expiration time of the root.
c. Or, are all certificates revoked?
They are revoked due to the fact that the root is revoked....Revoking
recursive could also be an option.
a. Is removal from the root list a revocation? Semantically, is
that what removal means?
Yes, kind of. In the relation we are discussing it, it is. However roots
can be removed and not be revoked, the root being used elsewhere.
Removal doesn't imply automatically revocation, it can however.
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?
Not that I'm aware of.
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.
That's maybe a case for removal but not necessary a case for revocation.
It would be a one-sided action by the software vendor as opposed to an
action by the CA itself.
d. Can Eddy send an unsigned email to Frank asking for revocation,
and explain how the entire hierarchy is toast because of some disaster?
No, Eddy has other means to contact Frank and similar vendors.
e. Can anyone else? :)
Asking yes. You can do that here.
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" ?
Supposed CRLs would work with NSS like they do with MS software, all
certificates issued by that sub root would be invalid. For NSS this
would have to be a OCSP response.
a. CAs probably want some defined way to do root revocation.
b. Audit criteria and practices generally require some
consideration to be in place for disaster recovery, which would
suggest the CA to have in place a root compromise & replacement plan.
Indeed! CAs MUST have a disaster recovery plan. I also advocate for a
fair treatment of the CA by the software vendors like Mozilla in order
to give the CA a fair chance to recover from the disaster. This should
work as an incentive for CAs to really come forward in an efficient way
to prevent havoc (in case the issue wasn't highly published elsewhere).
The CA should be able - after discovering and correcting the error which
led to the compromise - to issue a new root and re-issue all
certificates and have the new root included in an efficient manner.
There shouldn't be too many strings attached - however a re-audit within
a reasonable time should be made mandatory (due to the lack of a yearly
audit requirement here).
d. Does Mozilla have an interest in stating some additional things
here, or is it content to leave it up to general business and/or
audit considerations?
Beyond the above principal (if Mozilla decides to adopt it), the current
industry practice and audit requirements seem to me sufficient.
6. A somewhat contrary position is that "the root should never be
compromised."
Yes :-)
But there are scenarios this could happen - even if technically it
wouldn't be possible to compromise the root.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
