On Mon, Oct 20, 2008 at 5:31 PM, Julien R Pierre - Sun Microsystems <[EMAIL PROTECTED]> wrote: > > If the root could "revoke itself", in the case of root cert key compromise, > ie. the root cert's private key becoming public, anybody could then sign > revocation information for that root CA - whether to mark it revoked or > unrevoked. The revocation therefore always has to come from a higher level > than the root cert iteslf.
I would think that it would be easier just to say that if a root is EVER marked revoked, it should be automatically untrusted. (the 'suicide note' concept.) (Perhaps I'm thinking of something far too much like PGP's capability to revoke assurances on identities associated with a key, and the ability of a key to sign a revocation certificate for itself that can be propagated to the keyservers. I don't know if X.509 or the PKIX has a means of creating a separate revocation certificate which can be considered bound to the key the same way an identity can be bound.) > There are several solutions in the case of NSS/PSM : > 1) update the root cert module to one that no longer includes those root > certs > 2) update the root cert module to one that includes those root certs, but > has them explicitly marked untrusted > 3) without updating any software, marking the compromised root cert as > untrusted . This can be done manually in PSM . Another problem with X.509 is one that MS's "Friendly Certificate Name" concept was supposed to handle... the CA is identified by the CA's Subject Name, and authenticated with its public key. This means that it's very difficult to change the Subject name to include information like "compromised and untrusted as of [date]" so that people don't blithely add trust flags that have been removed by people who have more information. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
