2008/10/22 Ian G <[EMAIL PROTECTED]>: >>> Quite right. The flip side of this is that if *anyone* other than the >>> person who generated the key pair has they public key, they *should* >>> sign the suicide note and distribute it because if they have it, a bad >>> actor could have it as well. > > > I think we all understand that the basic concept of a root-signed > self-revocation is workable, in principle, at the information level. > > There may be substantial implementation questions...
There are those who don't think so, since the operations defined at the Root level include "revoking certificates" as well as "derevoking certificates", via CRL. There is no such thing as a "suicide note" in X.509 or PKIX. (I was actually just thinking of this when I was trying to get a root -- not in my control -- to mark a couple of certificates as revoked due to key compromise. If there were such a thing as a "suicide note", I could mark my own certificate as revoked and then submit it to the CA for additional processing [such as adding it to CRLs and OCSP responses].) >> Yes, they should ... But the big question is how do they actually do >> that and get software to take notice of that suicide note ? > > > Is there any reason why the message cannot be delivered by the > current channels? CRL, OCSP? Leaving aside the standards question, > that is... CRLs are signed by the root itself. The CRL can be reissued by anyone who has the key. OCSP is usually handled by a delegated responder with its own identity binding (and its own key). OCSP should be able to handle the case of "the root is compromised" by responding to all certificates with serial numbers in that root's space as being "invalid, key compromise". However, this relies on the ability of the OCSP responder to operate with a known-revoked certificate. > Is a self-reference in a CRL or OCSP: > > defined? Banned? Undefined? Going to cause chaos? Self-reference in CRL isn't a singular thing. Anyone with the root key can reissue a CRL. GoodGuy issues one with the self-reference saying "revoked, key compromised". BadGuy issues one with the self-reference missing, since BadGuy wants people to still trust the root. Thus, it's chaotic. OCSP I've mentioned above. > (Where, Chaos is defined as making matters worse for the software > that otherwise has to deal with a rogue root out in the wild serving > up the devil's contract every 3rd packet to grandma...) > > It would seem that, if the root list is delivered by party A, and > the software is written by party A, and the revocation is > distributed to software of party A, then it should all tie together. > > (Yes there will be some issues with party B. Refer to definition of > chaos.) I'd like to see Mozilla run its own CA and cross-certify its root list. That way, Mozilla would be the "higher authority" and could issue non-chaotic root revocations... by revoking the cross-certifications. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
